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Abstract 

The interaction of pattern-directed invocation with equality in an automated 
reasoning system gives rise to a completeness problem. In such systems, a demon 
needs to be invoked not only when its pattern exactly matches a term in the 
reasoning data base, but also when it is possible to create a variant that matches. 
An incremental algorithm has been developed, which solves this problem without 
generating all possible variants of terms in the data base. The algorithm is shown 
to be complete for a class of demons, called transparent demons, in which there 
is a well-behaved logical relationship between the pattern and the body of the 
demon. Completeness is maintained when new demons, new terms, and new 
equalities are added in any order. Equalities can also be retracted via a truth 
maintenance system. The algorithm has been implemented as part of a reasoning 
system called BREAD. 
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1 Introduction 

Pattern-directed invocation and equality reasoning are two techniques com- 
monly used in automated reasoning systems. This paper describes a problem 
that arises when these two techniques are combined, and gives a solution. 

1.1 A Simple Example of the Problem 

Suppose we are reasoning about a function, /, which obeys the axiom 

Vaj/(0,a:)>0. 

A typical implementation of this axiom is a demon with the pattern /(0, Ix) 
and a body that asserts /(0, Ix) > 0. 1 This demon can be thought of as 
instantiating the universally quantified axiom above for appropriate terms in 
the reasoning data base. For example, when the term /(0, c) is added to the 
data base, this demon is invoked and asserts /(0, c) > 0. 

In the presence of equality, however, the proper conditions for invoking 
a demon become more complicated. Suppose, for example, that the term 
f(a, b) is added to the reasoning data base and the equality a = holds. 
In the usual algorithm for pattern-directed invocation, nothing will happen, 
since there is no term in the data base that exactly matches the pattern of the 
demon. This is undesirable, however, because we would like the reasoning 
system in this situation to deduce f(a, b) > 0, which follows logically from 
the axiom above. We describe this problem as a lack of completeness in the 
pattern-directed invocation. 

Note, however, that if the term /(0, b) is somehow created in this situa- 
tion, the desired deduction will be made. The term /(0, b) exactly matches 
the pattern of the demon, which then asserts /(0, b) > 0. Since /(0, b) is 
equal to /(a, b) by substitution of equals (0 for a), equality reasoning further 
deduces that /(a, b) > 0. 

Thus, a brute- force approach to the lack of completeness in standard 
pattern-directed invocation is to close the data base under substitution of 
equals. This approach is not feasible, however, because the numbers of terms 
generated grows exponentially with the number of equalities, and is infinite 
in the case of recursively defined equalities. 



Variables are denoted, as usual, by the prefix "?". 



2 Pattern-Directed Invocation 

The algorithm developed in this paper solves the completeness problem 
by generating a subset of all possible substitutions, based on an analysis of 
the patterns of existing demons. Furthermore, the algorithm is incremental. 
New demons, new terms, and new equalities can be added in any order, and 
completeness will be maintained. Equalities can also be retracted. 

1.2 Outline of the Paper 

Section 2 provides additional background of the completeness problem and 
sets the stage for the rest of the paper, including defining the terminology 
that will be used. In addition to pattern-directed invocation and equal- 
ity reasoning, Section 2 introduces a third component, truth maintenance, 
into the environment in which the algorithm operates. Among other things, 
this means that completeness needs to be maintained when equalities are 
retracted. 

Section 3 formally defines completeness for a given data base of terms 
and set of demons. Examples are given of demons with simple and more 
complex patterns to illustrate the subtlety of the issues in the most general 
case. Finally, Section 3 defines the notion of a transparent demon and then 
proves a key theorem that is the basis of the algorithm of Section 4. 

Section 4 develops an algorithm that incrementally maintains complete- 
ness given new demons, new terms, and changing equalities. The devel- 
opment starts with a simple generalization of the standard algorithm for 
pattern-directed invocation, and then adds special processing for demons 
with complex patterns. Section 4 also discusses termination of the algorithm 
and some extensions that improve its performance. 

Section 5 concludes with a discussion of alternate approaches and related 
work. 



2 Background and Environment 

The completeness problem described briefly above first came to our atten- 
tion when we began to use McAllester's Reasoning Utility Package (rup) [5] 
in our research related to reasoning about programs [8]. Among other facili- 
ties, RUP included equality reasoning, a primitive pattern-directed invocation 
mechanism (demons were associated with operator symbols), and a truth 
maintenance system. We used these facilities to build up a library of demons 
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for reasoning about various algebraic properties of operators. Since our rea- 
soning also involved asserting and retracting equalities between operators, 
we immediately began to run into the incompleteness problem. 

In our successor to RUP, called BREAD (for Basic REAsoning Device), we 
have extended RUP to support a full pattern-matching language with vari- 
ables, and have implemented the complete algorithm for pattern-directed 
invocation described in this paper. BREAD also includes further evolved 
versions of RUP's truth maintenance and equality reasoning components. 
BREAD is now the kernel of a general-purpose knowledge representation 
and reasoning system, called FRAPPE [2], which is itself the foundation of 
a special-purpose system for reasoning about programs, called CAKE [7]. 

Pattern-directed invocation, equality reasoning, and truth maintenance 
are common components of many reasoning systems. In order to facilitate the 
incorporation of our algorithm into other systems, we attempt in this paper, 
as much as possible, to abstract away from details that are idiosyncratic to 
BREAD. In this vein, the following sections summarize the essential properties 
of pattern-directed invocation, equality reasoning, and truth maintenance 
that are relevant to our algorithm. 

2.1 Pattern-Directed Invocation 

Pattern-directed invocation is a common technique used in reasoning sys- 
tems, wherein a given procedure is to be applied to every term of a particu- 
lar form in the data base. The procedure is associated with a pattern. The 
combination is typically called a demon; the procedure is called the body of 
the demon. 

Whenever a new term is added to the data base, it is matched against 
the pattern of each demon. If the pattern matches, the body of the demon is 
applied to the matching term. (It is often convenient to also supply the set 
of bindings to the pattern variables as an argument to the body, although 
this can be computed from the matching term). Similarly, whenever a new 
demon is added to the system, its pattern is matched against all terms in 
the data base, and the body of the demon is applied to each matching term. 
In most implementations of pattern-directed invocation, elaborate indexing 
structures are used to make these matching processes efficient. 

In general, both terms and patterns can be hierarchical. An atomic term 
is a single symbol, such as / or 0. Non-atomic terms are built up by applying 
operators to arguments, recursively, such as /(0, b) or P(f(a,b),c). 



4 Pattern-Directed Invocation 

Patterns are written using the same notation as terms, except that vari- 
ables may appear in some positions. (Technically, a pattern may have no 
variables. This degenerate case occurs in several examples in Section 4.4.) 
Patterns are not, however, stored in the term data base — they are only as- 
sociated with demons. 

A Sat pattern is a list of terms and variables, such as /(0, ?a;) or 
P(/(a, &),?#). A flat pattern has all of its variables at "top level". A pat- 
tern with variables at other than top level is called a nested pattern. For 
example, P(/(?x,?y),?t/) is a nested pattern. The pattern f(7x,?y) is called 
a subpattern of P(/(?a;, ?y), 1y). 

The algorithms in this paper treat all the positions of patterns and terms 
symmetrically. Therefore, there is nothing to prevent the use of patterns 
with variables in the operator position, such as ?/(0,6). 

The notation used for demons in this paper is illustrated below: 

( /(0,?ar) , Xt . assert(* > 0) ). 

This is the demon introduced in the simple example problem in Section 1.1. 
The body of the demon, which may be an arbitrary procedure, is applied to 
a matching term t. Assert is the primitive that makes a premise. 

The demon above is an example of a common form of restricted demon, 
in which the body is simply a call to assert, with its argument constructed 
from parts of the input term. This form of demon is usually defined using a 
notation that makes the assert implicit and uses variables to define the body, 
as illustrated below: 

Rule /(0, ?*) =*> /(0, lx) > 0. 

With this form of demon, the bindings returned by the matching process 
are substituted in the right-hand side of the rule before it is asserted. In 
implementations of pattern-directed invocation, such as BREAD, which allow 
arbitrary procedures in demon bodies, this rule notation can be compiled 
into a procedure. 

A standard algorithm for pattern-directed invocation is given in Figure 1. 
It will serve as the starting point for the complete algorithm developed in 
Section 4. Note that in Figure 1 and elsewhere, we use the notation a = b 
to mean "a is identical to 6" (i.e., they are spelled the same), versus a = 6, 
which means "a equals 6" in the current equality relation. 
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1 function match(p, t, B) 

I Match pattern p to term t with bindings B. ] 

2 case 

3 p is a variable: 

4 if p is bound to s in B 

5 then if s = t 

6 then return B [ same vaiue ] 

7 else fail [ different value J 

8 else return B\j{p <— t} [ new binding ] 

9 p is a pattern po(pi, • • • , Pn)' 
10 if t is a term t (ti, . . . , t n ) 

n then for i in {0, . . . , n} do B <— match(p t , t,, 5) 

12 return i? I aii positions match ] 

13 else fail 

14 p is a constant: 

15 if p=i then return 5 

else fail 



16 



17 function try(£, p, d) 

[ Match term t against pattern p and apply body d if successful. 

18 B *— match(p, i, 0) 

19 if match succeeded 

20 then apply d to t [and B] 

21 function add-term(i) 

[ Add new term t to data base. ] 

22 for each demon ( p , d ) 

23 try(*,p,d) 

24 add t to data base 

25 function add-demon(p, d) 

[ Add demon with pattern p and body d. ] 

26 for each term t in data base 

27 try(tf,p,«0 

28 add ( p , d ) to demons 



Figure 1. A standard pattern-directed invocation algorithm. Note that the match 
procedure returns a set of bindings when it succeeds. Failure to match at any level 
is assumed to propagate to the top level. 



6 Pattern-Directed Invocation 

2.2 Equality Reasoning 

Reasoning with changing equalities involves two main tasks. The first task is 
to maintain the equivalence classes of the equality relation under transitivity 
and reflexivity. These classes need to be joined or split when equalities are 
asserted or retracted. 

The second task is to guarantee that all the variants of a term are in 
the same equality class. A variant of the (non-atomic) term t is any term 
derived from t by substitution of equals. Variants of t are therefore equal 
to t. For example, f(g(a,b),c) is a variant of f(d,e), given the equalities 
d = g(a, b) and e = c. The task of keeping variants in the same equality class 
is sometimes called the congruence closure problem, because it has been 
shown to be reducible to the problem of computing the congruence closure 
of a relation on a graph (for a formal definition, see [6]). 

The set of all possible variants of a term grows exponentially with the 
number of applicable equalities. For example, given a = b and b = c, there are 
eight possible variants of f(a, b). Moreover, the set of all possible variants is 
potentially infinite. For example, there are infinitely many variants of h(a), 
given the recursive equality a = h(a). 2 It is therefore obviously not feasible to 
solve the completeness problem by creating all possible variants of all terms 
in the data base. 

Note that equality reasoning does not, by itself, add new terms to the 
reasoning data base. All that equality reasoning does is update the equality 
classes on existing terms when equalities change, and place newly created 
terms into the correct equality class. 3 

The equality reasoning algorithm used in BREAD is due to McAllester [4]. 



2.3 Truth Maintenance 

Nonmonotonic reasoning is a common feature of many kinds problem solving, 
such backtracking search or hypothetical reasoning. In such cases, proposi- 
tions in the reasoning data base sometimes need to be retracted along with 



2 Such equalities are also often called "circular", because they correspond to cycles in 
the graph of the equality relation. 

3 The equality reasoning in BREAD actually does create new terms for efficiency reasons 
related to retraction of equalities. However, these are specially managed so that they do 
not interact with pattern-directed invocation. 
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their consequences. The collection of facilities to support this kind of rea- 
soning has come to be called a truth maintenance system (TMS) [1, 3]. 4 

The most basic function of a TMS is to keep track of which propositions 
in the reasoning data base are supported by the current set of premises. A 
proposition is a boolean- valued term. For example, both a+1 and a > are 
terms, but only a > is a proposition. A premise is a proposition that is 
believed without support. 

Reasoning procedures interface with a TMS by asserting and retract- 
ing premises and installing dependencies between propositions. To assert 
a proposition means to make it a premise. This is a monotonic change — it 
can only expand the set of supported propositions. To retract a premise 
means to remove it from the current set of premises. This is a nonmonotonic 
change — the set of supported propositions can shrink as a result. 

The main task of the TMS is to incrementally keep track of which proposi- 
tions in the reasoning data base are supported, as premises are asserted and 
retracted. A proposition is supported if and only if all of the propositions it 
depends on are either premises, or are supported. Like equality reasoning, a 
TMS does not, by itself, create or destroy terms. 

There are many other important issues in the implementation and use 
of a TMS not discussed here, because they are not relevant to the algorithm 
developed here. 

A reasoning system that is constructed using a TMS must obey a stringent 
discipline of installing the appropriate dependencies whenever deductions are 
made. For example, the following section describes the interface between 
equality reasoning and truth maintenance. 

2.4 Equality and Truth Maintenance 

In this paper, we assume (as is the case in BREAD) that equalities are propo- 
sitions in the reasoning data base. This does not contradict the claim that 
equality reasoning per se creates no new terms. For example, if some rea- 
soning process is interested in whether a is equal to c, given the premises 
a = b and b = c, it would typically add the proposition a = c to the data base. 



4 This is somewhat a misnomer, since the system isn't really concerned so much with 
what is true, but rather the reasons for believing things. Some attempts have been made 
to relabel these systems as "belief maintenance", or "reason maintenance", but none of 
these terms has stuck. 
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Equality reasoning then installs the appropriate dependencies (transitivity), 
from which the TMS concludes that a = c is supported. 

A similar process takes place with reasoning by substitution of equals. In 
the example of Section 2.2, the equality between variants 

f{g(a,b),c) = f(d,e) 

depends on the equalities used in the substitution: 

d = g(a,b), 
e — c. 

Note, however, that even if these supporting equalities are retracted, it is 
still possible for f(g(a,b),c) = f(d,e) to be a premise or be supported for 
other reasons, i.e., the two terms could be equal but not variants. This will 
turn out to be an important consideration in the development of algorithm 
for pattern-directed invocation. 

Another part of the interface between between equality reasoning and 
the TMS concerns the special case of equality between propositions (boolean- 
valued terms): A proposition is supported if it is equal to a supported propo- 
sition. For example, the proposition Q can depend on the proposition R and 
the equality Q = R. Similarly, the proposition P{a) can depend on the propo- 
sition P(b) and the equality P(a) = P(6), which itself depends on the equality 
a = b. 

3 Completeness and Transparency 

We begin this section with a formal definition of completeness. The notion 
of equivalent variants is then introduced and used to define a transparent 
demon as one that has logically equivalent results when applied to equivalent 
variants. The section culminates in a theorem establishing an implementable 
constraint on pattern-directed invocation that guarantees completeness for 
transparent demons. The algorithm developed in Section 4 maintains this 
condition incrementally. 

3.1 Completness 

The intuitive notion of completeness is that we want to create enough variants 
of terms in the data base to make use of all the knowledge in the demons. 
We can define this more formally as follows. 
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Definition. A data base of terms is complete with respect to a 
given set of demons if and only if applying demons to matching 
variants of terms in the data base does not change the equality 
theory of the data base. 

The equality theory of a data base is the set of propositions that follow logi- 
cally from supported propositions in the data base by the axioms of equality 
(transitivity, symmetry, refiexivity, and substitution of equals). Note that 
this defines completeness for a given (fixed) data base; the purpose of the al- 
gorithm in Section 4 is to guarantee completeness incrementally when demons 
and terms are added and equalities change. 

3.2 Equivalent Variants 

The definition of completeness above can be satisified trivially (at least in 
the absence of recursively defined equalities) by applying demons to all pos- 
sible variants of every term in the data base. In this section we define an 
equivalence relation on variants that helps characterize which variants are 
necessary for completeness, and which are not. 

Let us return to the simple example demon introduced in Section 1.1: 

Rule /(0,?x) ==> /(0,?x) > 0. 

Suppose the term /(a, b) is in the data base, and a = and 6=1. Given 
this equality relation, the set of possible variants of the term f(a, b) is 

{/(a,l),/(0,6),/(0,l)}. 

The first variant, /(a, 1), doesn't match the pattern of the demon, so it 
clearly does not need to be created. The second and third variants both 
match the pattern. Only one of these variants is necessary, however, to 
conclude that 

/M)>o. 

If the demon is applied to the variant /(0, 6), it will assert 

/(0,6)>0, 

from which /(a, 6) > follows by equality. Alternatively, if the demon is 
applied to /(0, 1), it will assert 

/(0,1)>0, 
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from which f(a,b) > follows by equality. (The algorithm in Section 4 
chooses /(0, b) for reasons which will be explained later.) 

In the case of flat patterns, only one variant is necessary to achieve com- 
pleteness. The main complexity in the completeness problem arises in the 
case of nested patterns. To illustrate, consider the following demon 

Rule P{h{1x)) =» P(h(?x)) -* Q(?x), 

which implements the axiom 5 

Vx P{h(x)) -+ Q(x). 

Suppose the term P(c) is in the data base, and 

c = h(a), 
c = h(b), 

but it is not the case that a—b (i.e., h(a) and h(b) are equal, but not variants). 
The set of matching variants of P(c) in this situation is 

{P(h(a)), P(h(b))}. 

In this case, both of these variants are needed for completeness. If only 
the variant P(h(a)) is created, then the demon will assert P(h(a)) — ■» Q(a). 
If P(c) is true, Q(a) will be deduced, but Q(b) will not. Similarly, if only the 
variant P(h(b)) is created, then the demon will assert P(h(b)) — ► Q(b), but 
Q(a) will not be deduced. 

To make things even more complex, now suppose in addition that 

a = d, 

b = e. 

There are now two more matching variants possible: P(h(d)) and P(h(e)). 
However, if the demon has already been applied to the P(h(a)) and P(h(b)), 
there is no need to create these two new variants, since applying the demon 
to them would result in the assertions P(h(d)) —> Q(d) and P(h(e)) — > Q(e), 
which follow by substitution from the assertions above. 

The reason why P(h(a)) and P(h(b)) are both needed is that they are 
equal by substitution at intermediate levels in the pattern P(h(?x)). In 



3 A concrete instance of this schema is the axiom Vx logx > — ► x > 1. 
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contrast, P(h(a)) and P(h(d)) are equal by substitution in positions occupied 
by variables in the pattern. Thus if the demon body does not depend on 
the internal structure of the variable bindings it gets, it cannot distinguish 
between P(h(a)) and P(h(d)) (this notion is formalized in the next section). 
In general, we can define the following equivalence relation on the set 
of variants that match a given pattern. Note that this definition involves 
only terms and patterns. The pattern of a demon is the only declarative 
information about a demon that will be available to the pattern-directed 
invocation algorithm. 

Definition. Two variants matching a given pattern are equiva- 
lent with respect to the given pattern and an equality relation if 
and only if they differ only by substitution of equals at positions 
occupied by variables in the pattern. 

Thus in the first example above, f(0,b) and /(0,1) are equivalent variants 
with respect to the pattern /(0,?a;) and the given equality relation. 

In the case of flat patterns, all matching variants are equivalent. This 
follows because two terms that match the same flat pattern can differ only 
at positions occupied by variables in the pattern. 

In the second example, the set of matching variants of P(c) is partitioned 
into equivalence classes as follows: 

{ { P(*(«)), P(Hd))}, {P(h(b)\ P(h(e))} }. 

To guarantee completeness with respect to this demon, we need to apply the 
demon to one variant from each of these classes. 

In the next section, the notion of equivalent variants is used together with 
the notion of transparent demons to prove the key theorem of the paper. 

3.3 Transparent Demons 

The two example demons in the preceding sections both have the property 
that equivalent variants are redundant. It is possible, however, to write 
demons that do not have this property. For example, consider the following 
demon as an alternate implemention of the axiom introduced in Section 1.1. 

( /(??/, 1x) , Xt . if h = then assert(* > 0) ). 
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(The symbols t , i 1? and t 2 denote the operator, first, and second argu- 
ments of the term t, respectively.) The problem with this demon is that it is 
hiding some of its pattern matching inside of the body, where it is inacces- 
sible to the pattern-directed invocation algorithm. For example, given a = 
and 6=1, the following set of matching variants are all equivalent: 

{/(a,6),/(a,l),/(0,6),/(0,l)}. 

However, if the demon is applied only to /(a, 6) or /(a, 1), the desired 
conclusion /(a, 6) > will not be deduced, because in both cases the condition 
in the body will be false and the demon will make no assertion. 

The property that this demon lacks, and which the other example demons 
in the paper thus far possess, can defined formally as follows: 

Definition. A demon is transparent if and only if it results 
in data bases with the same equality theory, when applied to 
equivalent variants with respect to its pattern and a given data 
base. 

One might think to define a transparent demon more simply as one that 
results in the same data base, when applied to equivalent variants. For 
example, the the demon above is not transparent, because the data base 
resulting when it is applied to the matching term /(0, b) includes the propo- 
sition /(0, 6) > 0, whereas the data base resulting when it is applied to the 
equivalent matching variant f(a,b) does not. 

However, consider the example of a transparent demon in Section 3.2. The 
data base resulting when it is applied to the matching term /(0, b) is not the 
same as the data base resulting when it is applied to the equivalent matching 
variant /(0, 1). (One data base includes the proposition /(0,6) > 0, while 
the other includes the proposition /(0, 1) > 0, and not vice versa.) However, 
the equality theory of the two data bases is the same (given a = and 6 = 1). 

Any demon written in the rule notation introduced in Section 2.1 is guar- 
anteed to be transparent. In general, the behavior of the body of a trans- 
parent demon must not be conditional on the values of its bindings, i.e., the 
subterms of the input term that correspond to variable positions in the pat- 
tern. (BREAD does not attempt to automatically analyze demon bodies to 
check this property.) 

The ultimate motivation for the definition of transparency above is the 
following theorem, which establishes an implementable constraint on pattern- 
directed invocation that guarantees completeness. 
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Theorem 1 (Completeness) A data base of terms is complete with respect 
to a given set of transparent demons if each demon is applied to (at least) 
one member of each equivalence class of matching variants of every term in 
the data base. 

The proof of this theorem is as follows. Consider applying a demon d to 
a matching variant v of a term t in the data base. The antecedent of the 
theorem states that d has already been applied to an equivalent matching 
variant v'. Since d is transparent, the data base resulting from applying d to 
v has the same equality theory as the data base resulting from applying d to 
v'. Therefore the data base is complete. 

We assume in the rest of this paper that demons are transparent, unless 
stated otherwise. 

3.4 Opaque Demons 

An opaque (i.e., non-transparent) demon can often be made transparent by 
removing conditionals from the body and changing the pattern. For example, 
consider the following opaque demon, which implements the idempotent law, 
Va; f(x, x) — x, for the operator /: 

( /(?x,?j/) , At. if t 1 = t 2 then assert(i = <i) ). 

This demon can be rewritten in the following transparent form: 
Rule /(?*, ?aj) =► f{1x,lx) = lx. 

It might occur to the reader to try to make the opaque demon above 
transparent by replacing t\ = t 2 by ii = t 2 in the body. Although, technically 
speaking, the demon in this form would be transparent, it would not be a 
very good implementation of the idempotency law, for two reasons. First, 
the law would only be instantiated for applications of / that are added to 
the data base after the equality between t\ and t 2 is established. Second, 
if the equality between i x and t 2 is later retracted, the proper dependencies 
have not been installed to cause t = t\ to be retracted also. 

If there is more than one conditional in the body of a demon, it may be 
necessary to break it up into several transparent demons, corresponding to 
the different cases. For example, the following opaque demon 
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( /(?rr, 1y) , A* . case 

t\ = 0: caseo 
<i = 1: casei ) 

can be rewritten as the following two transparent demons: 

( /(0,?y) , \t. caseo ) 
( /(l^y) » Ai.casei ) 

Not all opaque demons can be handled in this way. For example, consider 
the following opaque demon: 6 

( /(?a;,?y) , A* .if lt(i l5 1 2 ) then assert(* > 0) ). 

There is no way to make this demon transparent simply by giving it a 
different pattern or expanding it into a (finite) number of demons with the 
same body. To guarantee complete use of the knowledge in this demon, it 
would have to rewritten as 

Rule/(?x,?y) =► tx < ?y -► /(?*, 1y) > 0. 

This version of the demon has the disadvantage that it will instantiate the 
right-hand side for all applications of /. However, it does enable proving 
that /(a, b) > when only the relationship between a and b is known, not 
their specific numerical values. 

4 Development of the Algorithm 

In this section we develop a complete algorithm for pattern-directed invoca- 
tion in two stages. The first stage develops a complete algorithm for the case 
of flat patterns. The second stage reduces the case of nested patterns to flat 
patterns by introducing intermediate demons. 

Within the development of the flat pattern case, there are three steps. 
The first step, in Section 4.1, introduces a simple generalization of the stan- 
dard pattern-directed invocation algorithm, and shows that it maintains com- 
pleteness when new demons or terms are added. In Section 4.2, an additional 



6 Note that "It" is a test in the programming language, which is executed when the body 
of the demon is executed. This should not be confused with "<", which is the operator of 
a term in the data base. 
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procedure is introduced to maintain completeness when new equalities are 
asserted. Finally, in Section 4.3, we prove that no action is required when 
equalities are retracted, due to the use of the closest matching variant. 

Section 4.4 introduces the procedure the flattens nested patterns and 
proves that completeness is maintained in this case. Section 4.5 discusses 
termination of the algorithm. Section 4.6 describes some improvements to 
the algorithm that reduce the number of redundant proof paths. 



4.1 A Simple Generalization 

Figure 2 shows a simple generalization of the standard algorithm for 
pattern-directed invocation. The most basic change is that the identity (=) 
tests in lines 5 and 15 of the standard matching procedure have been re- 
placed by equality (=) tests. Thus, when match-w-equality succeeds, it does 
not necessarily mean that the given term matches the given pattern, but only 
that the given term or some variant matches the given pattern. The bindings 
returned by the matcher indicate a matching term. 

In line 21, the try-w-equality procedure, which is called whenever a demon 
or new term is added, uses the bindings returned by the matcher to create a 
matching variant, if necessary. (Substitute^, B) returns the pattern resulting 
from substituting the bindings B in the pattern p.) For example, when f(a, b) 
is matched against the pattern /(0,?a;), with a=0, match-w-equality succeeds 
and returns the bindings {?£<—&}. Try-w-equality then creates the matching 
variant f(0,b). 7 

Note that when a new matching variant term is created, the add-term- 
w-equality procedure is not called. This feature of the algorithm is crucial 
to its termination (see Section 4.5). The new term is in a sort of "limbo" 
state, in which it exists from the standpoint of the equality system, but not 
from the standpoint of pattern-directed invocation. This term will be added 
to the data base only if add-term-w-equality is explicitly called with it as an 
argument. 

Note also (line 22) that, when the matching variant (v) is already in the 
data base, try-w-equality does not apply the given demon, unless v = t. This 
is because under these conditions, the given demon will have been applied 



7 0ne might also think of simply applying the demon directly to the given term when 
the match succeeds, and never bothering to create the matching variant. This approach 
is discussed in Section 5.1. 
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1 function match-w-equality(p, t, B) 

\ Match pattern p to term t with bindings B with equalities. J 

2 case 

3 p is a variable: 

4 if p is bound to s in B 

5 then if s — t 

6 then return B [ same vaiue J 

7 else fail [ different value ] 

8 else return BU{p *— t} [ new binding ] 

9 p is a pattern p (pi, ..., p n ): 
10 if t is a term to(ti, . . . ,t n ) 

n then for i in {0, . . . , n} do 

12 5 <— match-w-equality(p,-, £,-, B) 

13 return 5 [ all positions match ] 

14 else fail 
is p is a constant: 

16 if p = t then return B 

17 else fail 

is function try- w-equality(t, p,d) 

[ Match term t against pattern p with equalities 
and apply body d to t or matching variant, if successful. ] 

19 B *— match- w-equality(p, t, 0) 

20 if match succeeded 

21 then v i— the-term(substitute(p,i?)) 

22 if v is not in data base or v = t 

23 then apply d to v [and B] 

Figure 2. A simple generalization of the standard pattern-directed invocation 
algorithm in Figure 1, which is complete for flat patterns only. (Continued on 
next page.) 
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24 function add-term-w-equality(£) 

[ Add new term t to data base with equalities. ]] 

25 for each demon ( p , d ) 

26 try-w-equality(£,p, d) 

27 add t to data base 

28 function add-demon-w-equality(p, d) 

[ Add demon with pattern p and body d with equalities. ] 

29 for each term t in data base 

30 try-w-equality (t,p,d) 

31 add ( p , d ) to demons 

Figure 2. (Continued) 

to v when try-w-equality was called on v, t, and d. It is necessary for this 
call to have occurred, since every term in the data base is tried with every 
pattern. Note that we are relying on the fact that the bindings returned by 
match-w-equality will correspond to its argument t if t matches the pattern 
with no substitutions. 

In certain circumstances, the algorithm in Figure 2 causes the same demon 
to be applied more than once to the same term. This inefficiency is eliminated 
in Section 4.6. 

The algorithm in Figure 2 is complete for flat patterns and a fixed equal- 
ity relation. It is clear by the definition of a variant, that the matcher is 
guaranteed to find a matching variant, if possible. In the case of flat pat- 
terns, all matching variants are equivalent, so only one matching variant is 
required to satisfy the condition of the Completeness Theorem. 

In the next two sections, we extend this algorithm to the case of changing 
equalities, but still considering only flat patterns. Following this, we treat 
the case of nested patterns. 

4.2 Changing Equalities 

When a new equality is asserted, two previously separate equality classes 
are joined. This in turn makes new variants possible. Any term with a 
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subterm in either of the two equality classes must be re-matched against the 
patterns of all demons (see Figure 3). Matches which failed before may now 
succeed. 

For example, suppose there is a demon with the pattern /(?#, 1). When 
this pattern is first matched against the term /(a, b), with a = and no other 
equalities, the match fails. If the equality 6=1 is asserted, however, the term 
/(a, b) needs to be re-matched (because it has b as a subterm). This time 
the match succeeds, yielding the matching variant /(a, 1). In BREAD, this 
re-matching process is made more efficient by indexing terms and patterns 
according the subterms that appear in them. 

When an equality is retracted, some of the variants of a given term match- 
ing a given pattern may cease being equal to the given term. This suggests 
that re-matching is also required when equalities are retracted. 

For example, consider the set of variants of /(a, 6) matching the pattern 
/(0, ?x), with a = and b= 1: 

{/(0,6),/(0,l)}. 

Since all of these equivalent, from the standpoint of the Completeness The- 
orem, it doesn't matter which is created for the demon to be applied to. 

Suppose that the variant /(0, 1) is chosen, and the demon from Section 1.1 
is applied to it. The demon asserts 

/(0,1)>0, 

from which the system can deduce by equality reasoning that 

/M)>0. 



1 function join-equality-classes(Ci, C-i) 

[ Join equality classes C\ and C<i. ] 

2 for each term t in data base 

3 if a subterm of t is in C\ U C2 

4 then for each demon ( p , d ) 

5 try-w-equality(i, p, d) 

Figure 3. Procedure to be executed whenever two equality classes are joined. 
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Now suppose that b = 1 is retracted, but a = remains. The system is now 
incomplete. In order to regain completeness, the pattern /(0,?a;) needs to be 
re-matched against f(a, 6), in order to create the variant /(0, b) and apply 
the demon to it. Note, however, that if f(0,b) were chosen in the first place, 
there would be no need for re-matching. 

The basic idea why it was a bad idea to choose the variant /(0, 1) above 
is because this variant uses more substitutions than necessary to match the 
pattern (e.g., substituting 1 for b was unnecessary). These extra substitutions 
make the deductive chain from the variant to the original term susceptible 
to be being broken when the irrelevant equalities (e.g., 6=1) are retracted. 
We formalize this notion in the next section, and show that the algorithm 
in Figure 2 always chooses a matching variant (e.g., /(0, &)), such that com- 
pleteness is guaranteed without re- matching on retraction of equalities. 

4.3 Closest Matching Variants 

The matching variant chosen by the algorithm in Figure 2 is as "close" as 
possible to the given term, in sense of depending on a minimum number of 
equalities. We call this variant a closest matching term, defined as follows. 

Definition. For a given term and flat pattern, a closest matching 
term is a matching term in which, for each variable in the pattern, 
the corresponding subterm in the matching term is identical to 
(at least) one of the corresponding subterms in the given term. 

Note that the definition of closest matching term does not involve the 
equality relation. Also, there is not always a unique closest matching term. 
For example, both /(a, a) and f(b, b) are closest matching terms for the term 
/(a, b) and the pattern /(?£, lx). (Section 4.6 describes an improvement to 
the matching algorithm which uniquely chooses a closest matching variant.) 
For a term and pattern that match without any substitutions, the closest 
matching term is (uniquely) the term itself. 

The important property of closest matching terms is given by the follow- 
ing theorem. 

Theorem 2 (Closest Matching Term) For a given term and flat pat- 
tern, if a closest matching term is not a variant, then there are no matching 
variants. 
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The proof of this theorem is more easily understood using the contraposi- 
tive form: If there is any matching variant, then every closest matching term 
is a variant. 

Let v be a variant of the term t matching the flat pattern p. Let c be a 
closest term to t matching p. Let ?x be a variable in p. Since v matches p, 
it must have the identical subterm v x in each position corresponding to Ix. 
Since c matches p, it must have the identical subterm, c x , in each position 
corresponding to ?x. Furthermore, since c is a closest matching term to 
t, c x must be one of the subterms of t corresponding to 1x. Since v is a 
variant of t, v x must be equal to each subterm of t corresponding to ?rc; in 
particular, v x = c x . Since v and c both match p, they can differ only in the 
variable positions of p. We have shown that, for an arbitrary variable ?x, 
the corresponding subterms v x and c x are equal; therefore c is a variant of v. 
Since v is a variant of t, c is also a variant of t. 

This theorem guarantees that no re-matching needs to be done when an 
equality is retracted. Patterns and terms that did not match before certainly 
will not match after the retraction. For patterns and terms that did match 
before the retraction, the body of the demon was applied to a closest match- 
ing term. If that term is no longer a variant after retraction, this theorem 
guarantees that there are no matching variants, so there is no point in trying 
to re-match. 

The use of the closest matching variant can lead to the creation of more 
than the minimum number of matching variants required to guarantee com- 
pleteness. It is essentially a trade-off between creating extra variants when 
a term is added to the data base versus extra matching when an equality is 
retracted. This trade-off is discussed further in Section 5.1. 

4.4 Flattening Nested Patterns 

The match-w-equality algorithm yields at most a single variant. Since we 
have already seen examples in Section 3.2 involving nested patterns, wherein 
more than one variant is needed to guarantee completeness, this algorithm 
is clearly incomplete for the general case of nested patterns. 

One might consider trying to directly generalize match-w-equality further 
to make it complete for nested patterns. This would entail matching against 
all members of equality classes at intermediate levels in a pattern. For ex- 
ample, in Section 3.2, when matching the pattern P(h(?x)) against the term 
P(c), one would match the subpattern h{1x) against all terms equal to c (not 
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only variants). In this case the equality class of c contains the terms h(a) 
and h(b). 

In the presence of changing equalities, however, this approach is not sat- 
isfactory, since it does not keep track of intermediate equalities (equalities 
corresponding to intermediate levels in patterns). For example, suppose that 
h(a) = h(b) is asserted only after the matching of P(h(lx)) against P(c) had 
been performed. The variant P(h(b)) will not be created unless the match- 
ing is re-done. This would require all terms and patterns to be re-matched 
whenever any equalities are added, making the cost of incremental assertion 
prohibitive. 

In this section, we show how to reduce the case of nested patterns to the 
case of flat patterns (for which we have a complete solution) by automat- 
ically defining intermediate demons. The basic idea of the reduction is to 
incrementally process nested patterns "from the inside out". When an at- 
tempt is made to add a demon with a nested pattern to the system, instead 
of adding it directly, we look inside the pattern to find a flat subpattern at 
some level of nesting. An intermediate demon is then added with that (flat) 
pattern and a body that "remembers" the pattern and body of the original 
demon. The rationale for this process is that, if there is no variant of a term 
in the data base matching the flat subpattern, then there certainly can't be 
a variant matching the whole pattern. 

When the intermediate demon is invoked, it uses its substitutions to make 
a new pattern with fewer variables. If this pattern is still nested, a further 
intermediate demon will be added for a flat subpattern, and so on. This 
process stops when there are no nested patterns left, at which point the 
original body gets executed. 

The algorithm which performs the incremental flattening process sketched 
above is shown in Figure 4. We will first explore its behavior with some 
examples, and then give a proof of its completeness in general. 8 

We illustrate the algorithm with the example from Section 3.2. The 
definition of the demon 

Rule P(h(?x)) =► P{h{1x)) -> Q(?x) 
results in the call 



8 Since match-w-equality will now only be called on flat patterns, the recursion in the 
definition of match-w-equality can be eliminated simply by "unrolling" the recursive call 
one level and then removing the recursive case. 
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1 function flatten(p, d) 

[ Add demon with possibly nested pattern p and body d. ] 

2 if p is nested 

3 then choose a subpattern pi of p 

4 flatten(p,-, XtB . flatten(substitute(p, B), d)) 

5 else add-demon-w-equality(p, d) [ Bat case ] 



Figure 4. The algorithm for adding a new demon with a pattern that may include 
subpatterns. Note that this is the tail- recursive definition of an iterative algorithm. 

natten(P(/t(?x)), body), 

which finds the flat subpattern h{1x) and adds the intermediate demon 

( fc(?x) , AtB.flatten(substitute(P(/i(?x)),5),&o<fy) ). 

(Note that we are assuming here that both the matching term t and the 
corresponding bindings B are passed to the body of a demon.) 
Given the term P(c) and the equality relation 9 

c = h(a), 
c = h(b), 

the pattern of the intermediate demon matches against the term h(a) return- 
ing the binding {lx <— a}. The body of the demon substitutes this binding 
in the pattern P(h(?x)) and calls 

&a,tten(P(h(a)),body). 

This call to flatten goes directly to the flat case, adding the demon 

( P(h(a)) , body ), 



9 It does not matter whether this term and equalities were present at the time the 
demon was added to the system, or whether they were added afterwards, since the system 
has already been shown to be complete for demons with flat patterns, regardless of the 
order of events. 
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which, when matched against the term P(c), causes the original body to be 
applied to the variant P(h(a)), asserting 

P(h(a)) -► Q{a). 

An analogous process starting with h(b) causes the body to be applied to 
the variant P(h(b)). As discussed in Section 3.2, these are the two matching 
variants of P(c) required for completeness. 

Note that even if the equalities 

a — d 
b = e 

are supported (or are asserted later), no additional variants are created, 
because h(d) and h(e) are equivalent to h(a) and h(b), respectively, with 
respect to the pattern h(?x). 

Additional example traces of the flattening of nested patterns are given in 
Figures 5 and 6. Figure 5 illustrates the flattening of a complex pattern with 
multiple variables and multiple occurrences of variables. Figure 6 illustrates 
that the final intermediate demon does not always have a degenerate pattern 
with no variables — it only must be flat. 

The completeness of the flattening algorithm is established by the follow- 
ing two theorems. 

Theorem 3 For a given term and demon, the flattening algorithm applies 
the body of the demon to at least one term from each equivalence class of 
matching terms. 

Theorem 4 For a given term and (possibly nested) pattern, if all of the 
variants created by the flattening algorithm in any equivalence class stop being 
variants, then there are no matching variants in that class. 

The proofs of both theorems are based on the following observation. Let v 
be some variant of t which matches p. Let 1x be some variable in p, and let v x 
be the corresponding subterm of v. Let p' be the first flat pattern containing 
1x which is added by flatten, and v' be the subterm of v corresponding to p'. 
If v' is present in the data base, it will match p' and v x will be substituted for 
?:r in further patterns generated in the process of obtaining a variant. If v' 
is not present in the data base, it must be a variant of some term s which is 
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Rule y(/(?z, ?y), /(?*, ?*)) =► *(/(?*, ?y ), /(?*, ?z)) = /(?*, y(?y , ?*)) 
Initial data base: 



9(r,s) 

r = /(a, 6) 
3 = f(d,c) 
a = d 



• flatten(y(/(?x, ?y), /(?x, ?*)), 6<Wy) 

> adds ( /(?:r, ?y) , body' ) 

where &oc?y' is AiZ?.flatten(substitute(y(/(?:r,?y),/(?;r,?z)), B), body) 

• f(a,b) matches /(?£, ?y) with bindings {lx «— a, ?y «— 6} 

> 6oiy' applied to /(a, 6) 

> flatten(y(/(a, 6), /(a, ?*)), tody) 

> adds ( /(a, ?z) , body" ) 

where 6ody" is \tB . flatten(substitute(y(/(a, b), f(a, 1z)), B), body) 

• f(d, c) matches /(a, ?z) with bindings {?z <— c} yielding variant f(a, c) 

> body" applied to /(a, c) 

> flatten(y(/(a, b), /(a, c)), body) 

> adds ( g(f (a, b),f (a, c)) , body ) 

• #(r, s) matches g(f(a, 6), /(a, c)) yielding y(/(a, 6), /(a, c)) 

> body applied to g(f(a, 6), /(a, c)) 

> asserts y(/(a, 6), /(a, c)) = /(a, y(6, c)) 

Figure 5. A trace of the process by which a demon implementing the distributive 
law for / over g is invoked in an example situation. 
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( f(h(?x),?y) , body ) 
Initial data base: 

f(c,d) 
c= h(a) 



• flatten(/(/»(?x),?j/), body) 
> adds ( h(tx) , body' ) 

where body' is XtB .flatten(substitute(/(/i(?x), ?y),B), body) 



• h(a) matches h(?x) with bindings {1x <— a) 
> body' applied to h(a) 

> flatten( f(h(a),?y), body) 

> adds ( f(h(a), ?y) , body ) 



• f(c,d) matches f(h(a),1y) with bindings {1y <— d} yielding f{h(a),d) 
> body applied to f(h(a),d) 

Figure 6. An example trace of the execution of a demon with a nested pattern, 
in which the final intermediate demon does not have a degenerate pattern. 
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in the data base, since otherwise v could not be a variant of t. When match- 
w-equality is called on p' and $ it must succeed, since there is a matching 
variant — v'. The bindings produced will have a subterm s x of s for ?x; since 
p' is flat, it must be the case that s x = v x holds (this part is similar to the 
proof of the Closest Matching Term Theorem for the flat case). In both 
cases, the process must finally yield a variant of t, since one such a variant 
is known to exist. 

We have shown that, for an arbitrary variable, a variant will be produced 
which has either the subterm of v corresponding to that variable or another 
term which is equal to it. Therefore that variant differs from v only in the 
positions occupied by variables in p, and thus is equivalent to v. Since v was 
an arbitrary variant, this shows that the algorithm will yield at least one 
variant from each equivalence class. 

Now consider the contrapositive of Theorem 4. Suppose after some 
changes to the equality relation, there is some variant v of t which matches 
p. From the argument above it follows that some equivalent variant of v has 
been added by the cascading algorithm. This variant must still be equal to 
v and therefore also to t. 

A final point to note about the flattening algorithm is that it can, in 
the worst case, lead to the creation of an exponential number of variants. 
Sometimes, all of these terms are necessary to guarantee completeness. 

In the case of flat patterns, each match between a pattern and a term 
can, in the worst case, lead to the creation of a single new variant. Therefore, 
the number of variants created by the algorithm will not exceed the product 
of the number of patterns and the number of terms in the data base. 

Consider, however, the nested pattern p(h(?Xi), . . . , h(?x n )) and the term 
p(c, . . . ,c), with the equalities c=h(a) and c = h(b). The flattening algorithm 
will substitute both h(a) and h(b) for each occurrence of c in the term. If 
h(a) and h(b) are not variants, then the exponential number of terms thus 
created are in fact all necessary for completeness. However, if h{a) and h(b) 
are variants (i.e., because a = b), all the terms created would be equivalent 
and any one would suffice. The algorithm is thus much less than optimal in 
this (relatively pathological) case. 

4.5 Termination 

Any pattern-directed invocation system (even without equality) has the 
problem that it is possible to write demons that cause the system to go into an 
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Rule h(h(lx)) =* h(h(lx)) = ?x 
Initial data base: 

h(h(a)) 



• 



• 



• 



flatten(ft(/i(?x)), body) 

> adds ( h{1x) , body' ) 

where body' is AtB.flatten(substitute(/i(/i(?a;)),B), body) 

h(a) matches h{1x) with bindings {1x <— a} 

> body' applied to h(a) 

> flatten(/i(ft(a)), body) 

> adds ( h(h(a)) , body ) 

h(h(a)) matches h(h(a)) 

> body applied to h(h(a)) 

> asserts h(h(a)) = a 

h(h(a)) matches h(?x) with bindings {1x <— h(a)} 

> body' applied to h(h(a)) 

> &a,tten(h(h(h(a))) , body) 

> adds ( h(h(h(a))) , body ) 

h(a) matches h(h(h(a))) [since a = h(h(a))] yielding h(h(h(a))) 

> body applied to h(h(h(a))) 

> asserts h(h(h(a))) = h(a) 



Figure 7. A trace of the process by which a demon implementing the involutive 
law for h is invoked in an example situation. Note that this example involves the 
circular equality h(h(a)) — a. 



• 
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• h(h(h(a))) matches h(?x) with bindings {1x *— h(h(a))} 

> body' runs on h(h(h(a))) 

> a,dd-demon(h(h(h(h(a)))), body) 

> installs ( h(h(h(h(a)))) , body ) 

• h(h(a)) matches h(h(h(h(a)))) [since h(a) = h(h(h(a)))] yielding h(h(h(h(a)))) 

> body runs on h(h(h(h(a)))) 

> asserts h(h(h(h(a)))) = h(h(a)) 



Figure 8. If matching variants created in try-w-equalities were added to the data 
base, then the example trace in Figure 7 would continue without terminating, as 
shown above. 

infinite loop. For example, when the term h(a) is added to the data base, the 
following apparently straightforward demon implementing the involutive law 
will create the terms h(h(a)), h(h(h(a))), h(h(h(h(a)))), and so on without 
end: 10 

Rule h(?x) =» h(hC!x)) = 1x. 

The problem with this demon is that it creates a new term in its body 
that matches its own pattern. Sometimes several demons can conspire to 
the get same effect, making the problem much less obvious. It is the user's 
responsibility to refrain from writing these kinds of demons. 

Non-terminating demons can often be rewritten so that they terminate. 
For example, Figure 7 shows the version of the involutive law used in FRAPPE, 
in which a larger pattern is used to avoid the termination problem. 

The example in Figure 7 also involves circular equalities and illustrates 
why it is important that matching variants (created in line 21 of Figure 2) 



10 This kind of non-terminating behavior is often called "counting", because it reminds 
us of the Peano axiomitization of the natural numbers. 
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are not added to the data base. As can be seen in Figure 8, if the matching 
variant h(h(h(a))) created at the end of Figure 7, were added to the data base, 
it would successfully match against the pattern h(?x), eventually causing the 
matching variant h(h(h(h(a)))) to be created, and so on ad infinitum. 

Despite the fact that it is always possible to write non-terminating demons, 
we do want to make sure that our extensions to the standard algorithm do 
not introduce any additional non-terminating behavior. One way of saying 
this more precisely is to prove that if all demons defined by the user have 
empty bodies, then the system will always terminate. 

For flat patterns, termination is obvious. There are a finite number of 
demons and a finite number of terms in the data base. The algorithm can, at 
worst, create one matching variant for each pair of term and demon. Since 
the bodies of the demons are empty, and add-term-w-equality is not called 
on the matching variant, the system stops when all of these variants have 
been created. 

For nested patterns, we have to worry about the intermediate demons 
created by the flattening process. All of these demons have flat patterns, 
but their bodies are not empty. Non-terminating behavior could result if the 
execution of the bodies created new demons ad infinitum. We can see this 
will not be the case, however, by observing that if there are variables in the 
pattern p of an intermediate demon, then the body of the demon is of the 
form 

XtB . flatten(substitute(p, B), body), 

where body is the original empty body. When a demon of this form is ex- 
ecuted, the substitution of bindings B in the pattern p must reduce the 
number of variables in the pattern. Eventually, a sequence of such calls must 
eliminate all of the variables in any pattern. When that happens, the call 
to flatten will go directly to the flat case and install a demon whose pattern 
has no variables and whose body is the original empty body, at which point 
the process terminates. 

4.6 Improvements to the Algorithm 

This section describes two extensions to the algorithm in Figure 2, which 
improve its performance. First, under certain circumstances, the same demon 
may be applied more than once to the same term. This problem is remedied 
by the addition of some indexing information on each term. Second, the 
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1 function try- w-equality(t, p, d) 

I Match term t against pattern p with equalities 
and apply body d to t or matching variant, if successful. ] 

2 B <— match- w-equality(p, t, 0) 

3 if match succeeded 

4 then v *— the-term(substitute(/>, B)) 

5 if (i> is not in data base and d is not in demon list of v) 

6 or (v = t and not joining equality classes) 

7 then apply d to v [and B] 

8 if v ^ t then add d to demon list of v 

Figure 9. An improved version of try-w-equality (see Figure 2), in which no 
demon is applied more than once to the same term. A list has been introduced in 
lines 5 and 8 to keep track of the demons applied to a given term while it is not 
in the data base. 

non-uniqueness of closest matching variants causes the algorithm to create 
unnecessary variants under certain circumstances. This problem is alleviated 
by the addition of an ordering on terms. 

The circumstances under which the same demon ( p , d ) is applied to the 
same term v more than once are as follows. Suppose that v is the matching 
variant created by try-w-equality(i,p, d), where t^v. Try-w-equality applies 
d to v, but does not add v to the data base. It is possible for the same term 
v to be created by a different call, try-w-equality^, p, d), where t^t'^v. 11 
In this situation, d will be applied again to v. Alternatively, suppose that 
v is now explicitly added to the data base, i.e., add-term-w-equality(u) calls 
try-w-equality(t;, p, d). Again, d will be applied to v. 

The problem here is that we don't know what demons have been applied 
to a term while it is in the "limbo" state (i.e., created but not in the data 
base). This problem is straightforwardly remedied by keeping a list of the 
demons applied to a given term while it is in this state. This list can be 
cleared and the memory regained in add-term-w-equality, when the term is 
added to the data base. 

Another case where the same demon may be applied to the same term 



n For example, let p be h{lx), v be h(a), t be j(a), and t' be it(a), with h = j = k. 
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more than once is when joining two equality classes. In that case, all demons 
have been applied to all matching terms in the data base, and the reason for 
re-matching is only to create new variants if appropriate. In that case there 
is therefore no need to apply the demon to the term t even if it matches the 
demon's pattern. 



The improved version of try- w- equality with these additions is shown in 
Figure 9. Note that the test v ^ t in line 8 checks for when try-w-equality 
is called from add-term-w-equality and t is being added to the data base, in 
which case there is no point in updating the demon list of t. 



A second problem with the algorithm in Figure 2 is it can create more 
matching variants than necessary for patterns with multiple occurences of a 
given variable. For example, consider matching the term /(a, b) against the 
pattern /(?#, 1x) with a = b. Both /(a, a) and f(b, b) are closest matching 
variants of /(a, 6) with respect to this pattern. Due to the order of matching, 
the algorithm in Figure 2 arbitrarily chooses to create /(a, a). Now suppose 
that the term f(b,a) is added to the data base. This term has the same 
two closest matching variants with respect to /(?x,?x), but in this case the 
order of matching in the algorithm chooses to create f(b,b). Since f(a,a) 
and f(b,b) are equivalent with respect to the pattern f(?x,lx), and both 
are variants of both f(a,b) and f(b,a), only one is required to guarantee 
completeness. 



This problem can be alleviated, with a small increase in the complexity of 
the matching algorithm, by introducing an arbitrary (e.g., lexicographic or 
timestamp) order on terms. When the matcher has a choice of bindings for 
a variable, it always chooses the smallest term in the order (see Figure 10). 
Thus in the example above, if lexicographic order is used, /(a, a) will be 
chosen as the closest matching variant for both f(a, b) and f(b, a). Note that 
as long as closest matching variants are used, it will sometimes be necessary 
to create more than one variant from each equivalence class. For example, if 
a,b,c and d are all equal, there is no one term which is closest to both f(a, b) 
and f(c,d) with respect to the pattern f{1x,1x). See however Section 5.1, 
where an alternative to using closest matching variants is discussed. 
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1 function match- w-equality(/>, t, B) 

[ Match, pattern p to term t with bindings B with equalities. 
Complete for Bat patterns only. ] 

2 case 

3 p is a variable: 

4 if p is bound to s in B 

5 then if s = t 

e then [ same vaiue J 

7 if t -< s then replace binding of p in B by 2 

8 return B 

9 else fail [ different value ] 
io else return B\J{p<— t} f new binding } 



li 



Figure 10. An improved version of the matching algorithm from Figure 2. Line 7 
has been added to guarantee that the matcher chooses the same matching variant 
for variant inputs. u t -< s" means t is less than s in some order. 



With Changing Equalities 33 

5 Conclusion 

5.1 Alternate Approaches 

The main goal of the algorithm developed in this paper has been to guar- 
antee the completeness of pattern-directed invocation without creating the 
potentially infinite set of all possible variants. As part of the development, 
however, a number of decisions have been made trading off between time 
(matching and demon execution) and space (term creation). These decisions 
have been based on the relative cost of various computations in our imple- 
mentation environment, and our expectations of use, such as the relative 
frequency of additions to the data base versus retractions. In this section, 
we briefly sketch two alternate decisions that could reasonably be made. 

In Section 4.1, it was suggested that, when match- w-equality succeeds, 
rather than sometimes creating a matching variant, one might always apply 
the given demon to the given term. For example, the term f(a, b), with a = 0, 
successfully matches against the demon 

( /(0,?z) , Xt . assert^ > 0) ), 

returning the bindings {lx <— b}. Rather than creating the new term /(0, b), 
one might consider applying the demon body to f(a, b) directly, causing it 
to assert f(a, b) > 0, which is the desired conclusion in this case. 

The problem with this approach is that the proper dependencies are not 
installed. The conclusion /(a, 6) needs to be retracted when the equality a=0 
is retracted. In order to make this approach work correctly, we would need 
to supply the body of each demon with with the set of equalities required to 
make the match succeed. 12 Any conclusions made by the body would then 
have to depend on these equalities. 

The attraction of this approach is that it can reduce the number of terms 
created. On the other hand, it can increase the number of demons applied. 
For example, suppose that in the situation above it is also the case that 
c = 0, and the term f(c, b) is in the data base. The algorithm developed in 
this paper will create the term /(0, 6), which is the closest matching variant to 
both f(a, b) and /(c, b), and apply the demon to it, asserting /(0, b) > 0. Both 
desired conclusions, namely f(a, b) > and /(c,6) > follow by substitution 

12 In the equality system of bread, it is very cheap to test if two terms are in the same 
equality class. It is much more expensive, however, to compute the supporting set of 
equalities. 
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of equals. The alternate approach suggested here will apply the demon twice, 
once to /(a, b) and once to /(c, b) to get the same conclusions. 

Another way to reduce the number of terms created, mentioned in Sec- 
tion 4.3, is to give up using the closest matching variant. For example, con- 
sider matching the term in the data base f(a,b) against the pattern /(0, ?x) 
with a = 0. The closest matching variant in this case is f(0,b) — if it doesn't 
already exist, the algorithm developed above will create it. However, suppose 
the term /(0, c) already exists (in the data base or in "limbo"), with b = c. 
This term is also a variant of /(<z, b) matching the pattern. Since all variants 
are equivalent in the flat case, completess is satisfied as long as the demon is 
applied to /(0,c). The term /(0, 6) does not need to be created. 

The problem with this approach, of course, is that when equality classes 
are split (e.g., when b = c is retracted), re-matching needs to be done, similar 
to when equality classes are merged. At that time, another existing match- 
ing variant may be found, or new term may need to be created. Whether 
this trade-off is advantageous depends on the relative frequency of additions 
versus retraction. 

Finally, a natural question to ask is whether the algorithm developed 
here can be generalized to unification, i.e., allowing terms in the data to con- 
tain variables (under the usual convention that free variables are universally 
quantified). Although the matcher could be straighforwardly generalized to 
do unification, it turns out not to be of much use. 

To illustrate, suppose that the data base contains the term /(?w,?u). 
This term would unify with the pattern of the following demon: 

Rule /(?*, lx) =► /(?*, ?a?) = ?x. 

However, creating the unifying term /(?«, ?u) and applying the demon to 
it would cause /(?«, ?u) = ?« to be asserted, which doesn't add any new 
information about the original term /(?u,?u). The conclusion to be made 
here is that, in this setting, logical variables and pattern variables are different 
entities. 

While on the topic of unification, it is also worth pointing out related 
research on so-called "generalized unification" [9]. The problem studied in 
this work is unification/matching in the presence of implicit equalities due to 
some fixed theory, such as commutativity or associativity. In contrast, our 
work is concerned with matching in the context of an explicit data base of 
arbitrary, changing equalities. 
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5.2 Summary 

Pattern-directed invocation in the presence of arbitrary equalities raises the 
completeness problem addressed in this paper. If the equalities are fixed 
and patterns are flat, the changes that need to be made to the standard 
pattern-directed invocation algorithm are relatively straightforward. Chang- 
ing equalities and nested patterns introduce most of the complexity of the 
algorithm developed here. 

The algorithm described here has been implemented in a working sys- 
tem called BREAD. This system has proved to be a useful foundation upon 
which we have built a frame system [2] and a system for reasoning about 
programs [7]. 
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